The present invention relates generally to conflict resolution of a private internet protocol (IP) address in a virtual private network (VPN) using a remote access mechanism, and more particularly to conflict resolution of a private network IP address between internet protocol security remote access server (IRAS) and internet protocol security remote access client (IRAC) with IRAC being arranged behind a network address translator (NAT) in the network.
In a VPN remote access mechanism, the endpoint to security gateway tunnel deployment scenario of IP security (IPsec) VPN is implemented. Typically, the endpoint connects to a remote network such as a corporate office using an IPsec protected tunnel. The security gateway tunnel is used by the endpoint to either securely access the corporate network or to access the internet. The internet protocol (IP) address of the endpoint is not known to the security gateway prior to connection.
In such an environment, the endpoint is denoted as IPsec remote access client (IRAC). The security gateway at the corporate office is denoted as IPsec remote access server (IRAS). The IRAC requests the IRAS for an IP address associated with the security gateway to access the internal networks of the security gateway. The IP address assigned by IRAS is denoted as a virtual IP address. After connecting to IRAS, IRAC possesses two active IP addresses: the internet service provider (ISP) assigned address assigned to its physical interface; and the virtual IP address assigned by IRAS.
The IPsec remote access mechanism is explained by the following internet engineering task force (IETF) request for comments (RFC) standards: RFC 4306—Internet Key Exchange (IKEv2) Protocol; RFC 4301—Security Architecture for the Internet Protocol; RFC 2409—The Internet Key Exchange (IKE); and IETF draft document “draft-ietf-ipsec-isakmp-mode-cfg-05.txt”; and RFC 2408—Internet Security Association and Key Management Protocol (ISAKMP). As explained in the IETF documents, IRAC-IRAS data communication makes use of IPsec tunnel mode to send and receive packets. In each packet sent from IRAC, the outer IP header contains the source IP address associated with its current location. The source IP address associated with the current location is the address that will get traffic routed to IRAC directly. The inner IP header contains the source IP address assigned by IRAS. The source IP address assigned by IRAS is the virtual IP address that has traffic routed to IRAS for forwarding it to IRAC. The outer destination address is always an IP address of IRAS, while the inner destination address is the ultimate destination for the packet.
However, as the IRAC client is behind the NAT router, the IP address assigned to its physical interface might be a private IP address. If the network portion of the IP address happens to be the same as that of any of the internal networks on IRAS side, IRAC cannot access that particular remote network. For IRAC, that particular remote network appears to be directly connected to the physical interface and IRAC tries to resolve media access control (MAC) address using the address resolution protocol (ARP) for sending the packet via the physical interface instead of tunnelling the packet to IRAS.
There is a need for a method or system to solve or at least alleviate the problems discussed.